Records of all kinds often have some sort of unique identifier associated with them, so as to be able to distinguish one record from another. In computerized databases, the identifier is often a key used for retrieval of a particular record or records from the vast numbers of records that such databases can contain.
The needs or preferences of entities that maintain large databases of records may dictate particular, varying formats for record identifiers. Departments of governments, for example, may establish regulations mandating certain formats that can vary from department to department. The business world may have needs for record identifiers that vary in as many ways as individual businesses can vary. Businesses that do work pursuant to government contracts may in particular need to conform their record identification formats to government regulations. According to such regulations or other considerations, record identifiers might, for example, need to include mixtures of numbers and letters in specific combinations or sequences. For instance, for a group of related records, a part of their respective identifiers might be required to serialize the records to differentiate between records in the group.
Formats for record identifiers typically impose restrictions on the numbers of positions that can be assigned to respective parts of the identifiers. Such restrictions may be necessary, for example, due to space limitations on a form, or due to other factors. Whatever the reason for the restriction, if it is applied to a serializing portion of a record identifier, the restriction limits the number of unique combinations that can be represented. For example, assume that a government agency, the Agency of Large Databases (ALD), mandates a record identifier format for purchase orders as follows: department number-record creation month (in MMYY format)-project number-serial number of six digits. Thus, an example of a record identifier for the ALD might look as follows: ALD5-0604-035-000471. Here, the fields ALD5-0604-035 might be common to many records (all the purchase orders created in June of 2004 for project 035), while a serializing portion serial number of six digits differentiates between individual purchase orders. Because in this example the number of positions assigned to the serializing portion is six, the number of unique combinations that can be represented in terms of numbers alone is limited to one million (000000, 000001, 0000002; . . . , 999999).
However, the number of records in a database that need to be assigned unique serializing portions can easily exceed one million. Even if the serializing portion is allotted more positions—say, eight, or ten, or more—the number of unique representations possible with numbers alone is finite and may be exceeded by the number of records that need to be serialized. Accordingly, alphabetic representations (letter combinations) or alphanumeric representations (combinations of letters and numbers) may be used as an alternative to, or to supplement, strictly numeric representations of a serializing portion of a record identifier. Such alphabetic or alphanumeric representations may form some logical sequence that enables serialization of record identifiers in a way analogous to the way strictly numeric sequences can serialize record identifiers. For example, an alphabetic representation using three positions could be serialized as AAA, AAB, AAC, . . . , AAZ, ABA, ABB, . . . , ZZY, ZZZ. Or, for example, an alphanumeric representation of three positions could be serialized as AAA, AAB, . . . , AAZ, AA0, AA1, . . . , AA9, ABA, ABB, . . . , AB9, ACA, ACB, . . . , 99A, 99B, . . . , 999. Other arbitrary combinations of letters and numbers are possible that can function to serialize record identifiers.
Notwithstanding the advantages offered by alphabetic and alphanumeric combinations, processes to generate such combinations can be complex. Consider the following example. Assume the objective is to increase the number of unique combinations that can be made within four positions beyond 10,000 by using alphabetic and alphanumeric combinations as well as purely numeric combinations. A corresponding range might be defined as follows:    0001-ZZZZ
However, how counting should be performed within this range is not at all intuitively obvious. For example, suppose one counted, initially, by forming the strictly numeric combinations 0001, 0002, . . . , 0009. What the next combination should be is to a large extent arbitrary. For example, 000A is as reasonable a choice as 0010, given that letters are allowed within the range. Thus, one “logical” counting rule (based on an arbitrary desired usage) might look as follows:    0001-0009    0010-0099    0100-0999    1000-9999    000A-000Z    00AA-00ZZ    0AAA-0ZZZ    AAAA-ZZZZ.
However, a second counting rule that is just as logical (based on a different arbitrary desired usage) could look like:    0001-0009    000A-000Z    0010-0099    00AA-00ZZ    0100-0999    0AAA-0ZZZ    1000-9999    AAAA-ZZZZ.
In view of the above example, it may be understood that the question “what is the next combination in an alphabetic/alphanumeric sequence?” can be a difficult one to answer and depends on how the logic of the sequence is defined. It would of course be possible to write program logic to generate such sequences according to the respective needs of individual users, but executing the program logic to assign the serializing portions of record identifiers could be computationally expensive, especially in a large-scale and busy processing environment that generates many new records. Moreover, the latter approach requires coding a specialized solution for each individual user; a more generalized approach would be more efficient.